Hardware processors include one or more central processing unit (CPU) which each may further include a number of physical registers for staging data between memory and functional units in CPUs. The CPU may be programmed with instructions and micro-operations that include logical registers for accessing these physical registers. Table 1 is an illustrative example of instructions of a store and load operation pair which includes manipulation of logical register RAX. A Register Alias Table (RAT) is commonly used to track the mapping between logical registers (such as RAX) and their corresponding physical register inside the CPU.
TABLE 1RAX = first operation. . .Store [ADDRESS] ←RAX...RAX = Load [ADDRESS’]. . . second operation on RAX
Different methods may be used to efficiently utilize these registers. U.S. patent application Ser. No. 12/978,513 ('513 Application) uses a Move Elimination technique that implements logical register to logical register copy operation as manipulations inside RAT. Namely, instead of executing a copy operation in the CPU (which creates a separate physical register with the same data content), both logical registers are simply mapped to the same physical register inside the RAT. The complexity is that when one of the logical registers is overwritten and thus disassociated with the physical register, that physical register cannot be freed until the other logical register mapping has also been overwritten. In the 513 Application, a Multiple Instance Table (MIT) is used to track all of the logical register references to a particular physical register.
Memory renaming is another technique that exploits register to register copy operations that occur through memory. In this approach, the logical register's value is stored to memory and then loaded back into another register. As shown in Table 2, Since RAX and RBX hold the same data value as a result of load operation, the physical register initially mapped to logical register RAX can effectively also be remapped to logical register RBX. This may improve performance because the consumers of RBX no longer need to wait for the store and load to be completed for dispatch to the execution. Instead, the execution can start as soon as RAX is written by the “first operation.”
TABLE 2RAX = first operation. . .Store [ADDRESS] ←RAX. . . (no intervening write to [ADDRESS])RBX = Load [ADDRESS]. . . second operation on RBX
In both the Move Elimination approach and the Memory Renaming approach, the shared physical registers cannot be freed until all correspondingly mapped logical registers have been overwritten by an allocation operation (or allocator), and there are no more micro-operations remaining in the out-of-order execution engine that can still reference those physical registers. It is desirable to allow RAX and RBX as shown in the example of Table 2 to share the same physical register, even after RAX is overwritten; note that the old version of RAX may be still in use by the out-of-order execution engine. Since the old value used by the out-of-order execution engine does not have a current (allocation time) logical register name, it is problematic to use logical register names for tracking physical register sharing.